Mise à jour le 13/11/2021
PHP et son futur

PHP et son futur

1. LA page à connaitre pour faire de la veille en PHP

Il existe une page que je ne connais que depuis novembre 2020 et cette page a changé ma vie (enfin non, mais bon, c'est pour faire genre) : https://wiki.php.net/rfc

Cette page est peut être LA page qui permet de faire la veille la plus pragmatique que l'on puisse faire sur le PHP (et uniquement le PHP, cela ne couvre donc pas les frameworks, les autres bibliothèques et les autres langages, bien que certaines RFC y fassent parfois référence).

La page est découpée en plusieurs sections :

la section "Under Discussion" : ici tout se débat, tout se discute, ce sont les RFCs imaginées la veille après une bière de trop et écrites tout de même noir sur blanc et envoyé par email à la communauté PHP. C'est une section très riche pour la créativité car on parie un peu sur la pertinence de la proposition. Lorsque la RFC a été bien réfléchie passe alors l'étape du vote pour indiquer si oui ou non cela vaut le coup de l'implémenter dans le langage.
Lorsque les développeurs se sont mis d'accord sur l’intérêt de la RFC, c'est le moment d'en faire un papier un peu plus sérieux dans la section "In Draft", c'est l'étape de la conception et du développement. Lorsque celui ci est terminé, les développeurs votent à nouveau.

Suite au vote sur la RFC et l'acceptation de celle-ci, la RFC atterrit alors dans la section "Accepted", très chaud à ce moment là pour intégrer la version suivante du langage s'il s'agit d'une modification du code (parfois ce sont des RFC qui ne ciblent pas forcément le PHP).

la section "Implemented" qui veut dire que non seulement la RFC a été acceptée par l'équipe de développement mais en plus qu'elle fait partie intégrante de la version du langage ou des futures décisions.
Ce qui est intéressant lorsque l'on est simple utilisateur du PHP, c'est d'assister à ces réflexions extrêmement riches pour l'esprit. Non seulement elles permettent de comprendre pourquoi l'équipe de développement a validé ou non une idée mais en plus permet un allèchement non négligeable sur les futures montées de version.

On se pose également des questions légitimes comme "ha tiens c'est vrai que ça, ça existe sur d'autres langages, c'est étonnant et même curieux que non seulement ce ne soit proposé qu'à peine aujourd'hui mais surtout que l'on a réussi à s'en passer pendant toutes ces années" ; car c'est cela qui est assez magique avec les langages de programmations (oserais-je ajouter "Turingué" histoire d'appuyer le pléonasme) : dès lors que les fondamentaux existent (boucle/conditions/quelques types comme char, bool et float/modification de l'espace mémoire), tout le reste n'est que fioritures et gâteries pour le développeur (on appelle ça du sucre syntaxique).
Car honnetement : si la visibilité n'existait pas, ni les classes d'ailleurs, ni mêmes les types bool, int et même float, on pourrait s'en sortir uniquement avec des for et des string.

A noter qu'une RFC ne concerne pas uniquement une modification du code de PHP mais peut également agir sur la façon même dont les débats sont menés (ex: cette RFC qui revient sur une règle de vote des RFCs (c'est presque de l'inception comme ces parenthèses !))

2. Si quelqu'un sait pourquoi...

Ce qui est dommage avec ce système de RFC, c'est qu'il ne me parait pas possible de connaitre les motivations des votants.
Ainsi, même si on a l'intuition qu'une RFC n'est pas une bonne idée, il n'est pas possible de savoir si notre intuition est celle partagée par la majorité des votants ou si l'on est complétement à côté de la plaque.